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Abstract: In May 2016, the office of Finance and Sponsored Projects at The Research 
Institute at Nationwide Children’s Hospital conducted a 5-day design sprint session to 
re-evaluate and redesign a flawedfinal reporting process within the department. The 
department sprint was modeled after the design sprint sessions that occur routinely in 
software development and manufacturing processes fields. The Research Performance 
Progress Report (RPPR) process was not consistent among all Sponsored Project Officers 
(SPOs), and the department needed to develop and implement quality control measures 
to safeguard compliance and assure quality in the reporting process. This study in adapting 
a software design processfor use in sponsored projects assesses how this problem-solving 
mechanism can be utilized with success to replace the formal workgroup model and improve 
the research administration enterprise. Findings illustrate that several factors influence the 
success of the sprint application to research administration, including increased time spent 
dedicated to the probletn and a gained shared understanding ofthe probletn and possible 
solutions. Finally, findings indicate a strong preferencefor the individual problem-solving 
technique inherent in the sprint model in combination with the intense and deadline- 
driven collaboration mechanism. 

Keywords: sprint, agile methods, efficiency, work group, teams, organizational science, sponsored 
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Introduction 

Sprint design sessions are routinely employed by Google Ventures and at numerous other software 
companies both nationally and internationally (Knapp, Zeratsky, & Kowitz, 2016). The sprint 
model puts key members of the team in a room with a Decider and a Facilitator for six hours a day 
for five days to solve a problem, design a product, or develop a solution. Sprint team participants 
are forbidden from using cell phones or other technology while participating in the sprint session. 
By putting all stakeholders in a room, the sprint experience forces team members to commit to 
making progress, helps teams move abstract ideas and hunches into concrete action, keeps teams 
focused on what’s important, and encourages prompt decision-making and follow-up (Knapp, 
Sprint, 2016). The sprint also often makes use of a “scrum master,” whose job is to remind the 
team, via use of a bell or other sound device, when the team veers off-topic or begins developing 
solutions or ideas that may be valuable but are not applicable to the specific sprint goal. The sprint 
team must understand, map, develop, and test a working prototype in one week. A one-week 
deadline motivates sprint teams to produce quickly and efficiently. 
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Sprints are common in the development of websites, apps, and other software. Google Venture 
has also introduced the sprint model to manufacturing processes and seen successes emerge from 
its application in that field as well. The challenge in applying the sprint to sponsored projects 
is that research administration rarely develops a product or a single-user experience. Processes 
are multi-layered, over the span of a year or more, involve many players contributing to grant 
management, and must often be nimble and adaptable to changes in regulation or law. To meet 
the needs of research administration, the sprint concept would need to be modified to generate 
an improved process. 

Current Problem-solving Mechanisms 

Effective teamwork is key in research administration, and in all organizations. The Harvard 
Business Review published a study in 2016 that found that “the time spent by managers and 
employees in collaborative activities has ballooned by 50 percent or more” (Cross, 2016). The 
challenge is to make the most of these collaborative experiences. Sponsored Project offices 
typically employ long-term workgroups or committees. In these collaborative environments, 
team members meet for an hour each month or twice a month to analyze a process, project, or 
department need and to make recommendations for improvement and implementation. The 
workgroups use brain-storming, mapping, group discussion, and critical questioning to move 
towards recommendations and create deliverable materials that illustrate process changes or 
provide training. A variety of individuals with diverse roles appear as contributors on department 
committees. Workgroup duration commonly varies between several months to several years, with 
participation fluctuating with staff turnover and committee burn-out. The workgroup model of 
problem-solving has flaws. Progress towards solutions is slow, individuals miss meetings and lose 
motivation to contribute, staff turnover challenges process towards achieving goals, outspoken 
individuals in brainstorming sessions tend to drive progress in a single direction, schedules grow 
increasingly clogged by meetings, and department morale flags. Teams spend a long time on 
critical tasks, leading the project to fall behind, and can struggle to complete tasks and achieve 
their goals (Kisielnicki, 2016). 

Additionally, work groups strive to produce a final product or recommendation and do not 
experience critical iterative design sequences. These final products occur at the end of a work 
group’s convened effort. Redesign of those end products is slow and cumbersome since the time it 
takes to convene the work group, gather feedback on needed revisions, and collaborate on a new 
design stretches over weeks or months, sometimes years. Finally, the larger the work group size, 
the more prone its team members are to decreased individual effort towards accomplishment of 
the groups goal (Latane, 1979). Devine suggests “a great deal of time, effort, and perhaps money 
is spent in creating teams, but little is done for them once they are in place.” 

However, factors impacting team effectiveness are contingent on the team’s context (Devine, 
1999). Devine finds that organizations boast a variety of team types: management teams, 
autonomous work groups, semiautonomous work groups, and project teams. The sponsored 
projects department tends to rely on semiautonomous work groups, defined as a group of diverse 
co-workers tasked with a goal or problem to solve and that reports their recommendations to 
management. This problem-solving model assumes that problems are well defined, processes can 
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be optimized, and results can be predicted (Devi, 2013). The sprint model is an ad hoc project 
team, as defined by Devine, responsible for developing a specific project in a specified duration, 
tasked with being adaptive, collaborative, and in employing design iterations. 

Outside of the workgroup model, staff members choose to solve problems on their own and 
present possible solutions to managers, collaborate with each other on solutions via email 
communication, or discuss problems and possible solutions during department meetings. The 
workgroup model is the standard problem-solving mechanism endorsed by the sponsored 
projects department at The Research Institute at Nationwide Childrens Hospital. 

Rapid-response 

Google Venture’s 5-day sprint accelerates a teams understanding of the problem at hand and 
engenders in team members shared understanding of complexity and possible solutions. The 
sprint model offers an additional advantage in that it is a rapid-response solution team, capable of 
gathering feedback on a prototype and redesigning in real-time to meet the deadline. Sprints are 
commonly one piece of the Agile methodology in which projects are managed progressively, with 
iterations over time. These rapid-response iterations quickly incorporate feedback and redesign a 
product to eliminate unsuccessful product elements (Kisielnicki, 2016). The Sponsored Projects 
sprint encouraged iterative design in both the sketching and prototyping days. Iterative design 
elements are new and offer a potentially valuable alternative to the traditionally linear problem¬ 
solving methods evidenced in workgroups. 

Rethinking RPPR Submission 

In 2014, the National Institute of Health began requiring institutions to submit a Research 
Performance Progress Report (RPPR) for all annual, type 5 noncompeting NIH awards (National 
Institute of Health [NIH], 2014). In the RPPR, “recipients describe scientific progress, identify 
significant changes, report on personnel, and describe plans for the subsequent budget period or 
year.” It is essential to be accurate and timely in working with principal investigators to complete 
and submit RPPRs. 

From 2015-2016, the Sponsored Project Officer team replaced two of its four members and 
increased the team by an additional two new positions, growing the dedicated SPO team from 
four to six, including the transition of one SPO to SPO Manager. Consequently, two-thirds of 
the team was new to submitting RPPRs. The significant staffing changes, in combination with 
the implementation of the RPPR requirement, resulted in inconsistent submission and a lack 
of understanding among the SPO team members as to what was truly required on the report, 
whose role it was to collect and enter different pieces of the report, and how best to organize and 
communicate regarding the RPPR submission and due date. The director reported significant 
variation in the information he reviewed in the RPPRs submitted by the SPO team. These 
inconsistencies and errors required the institution’s signing official to return to the SPO at 
submission to gain complete information on publications, inventions, intellectual property, aims, 
and budgets before submitting the RPPR on behalf of the investigator. The process was time- 
consuming, inefficient, and inconvenient for all parties. Additionally, the SPO team was projected 
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to grow with the addition of another position, to seven in total by the fall of 2016, and would 
need a way to train that individual in RPPR submission or risk the same lack of understanding 
and errors in a new cycle. The SPO team needed to work together to outline best practices for 
submission, but the team was consistently buried in work and unable to determine how best to 
dissect the complex process from start to finish in order to educate new members of the team on 
the multilayered RPPR submission process. 

According to the National Institute of Health, “review of the RPPR by NIH staff is a key element 
in NIH’s monitoring of the grant award” and “funding for non-competing years of the grant 
can only be awarded after the NIH program and grants management staff review and approve 
the progress report” (2016). It was imperative for the SPO team to improve their submission 
process and better communicate with the signing official in order for the principal investigator to 
continue to receive timely non-competitive funding. Streamlined Non-Competing Award Process 
(SNAP) RPPRs are due 45 days from the next grant year budget period start date, whereas Non- 
SNAP RPPRs are due 60 days before the next grant year budget period. In optimal conditions, 
a principal investigator will initiate an RPPR 60 days before it is due, starting the clock on that 
submission for the Sponsored Project Officer team. Within that window, SPOs must often 
coordinate with subsites to gain budget information and documents, complete administrative 
sections of the report regarding budgets, effort, inventions, and more, and sometimes help train 
new investigators to use the system and complete their sections of the report. 

An RPPR User Guide exists to help guide research staff and investigators in submitting through 
eRA Commons (NIH, 2016), and yet, because the process involves several different handoff 
points and individuals along the way through the year of the award, and because each grant 
funding mechanism is unique, the reporting process is rife for complexity. While the SPO 
team acknowledged their use of the Instruction Guide in submitting their own RPPRs to the 
signing official, the team needed best practices in place for handoff, communication, training, 
and coordination among different roles that all play a part in a successful submission. The team 
needed to map the process to identify pressure points and common errors. 

An Alternative Problem-solving Model 

The Research Institute’s Sponsored Project Officer team was willing to pilot the sprint project 
in May 2016. There were a few key problems to overcome in adapting the sprint for sponsored 
projects. A review of the literature on sprints did not yield any instances of this model being 
employed in research administration or to retool a complex internal, multi-user process. The 
traditional sprint focuses on satisfying the needs of the customer and produces a product to meet 
that need. In seeking to re-invent the department process, the sponsored project sprint team 
would be its own customers and the product created by the sprint would be a process for their 
own use. Would this change the sprint’s success or value to the department ? 

Resource allocation was another hurdle in implementing the sprint in sponsored projects. Knapp 
advises a 5-day sprint, with each day consisting of 6 hours. The department could not afford to 
allocate all the Sponsored Project Officers, two Research Business Coordinators (RBCs), two 
Grants and Contract Officers (GCOs), and the SPO Manager, a total of ten staff, for six hours 


The Journal of Research Administration, (47)2 




98 Riiubenolt 


a day for five days, for a total of 300 hours. As a compromise, the department allocated two 
hours a day for five days—a significant reduction in allocation, yielding just 100 hours. It was an 
abbreviated version of a sprint, but would it still work? 

Conducting the Sprint 

The Google Venture team recommends specific tasks for each day of the design sprint. The first 
day would be dedicated to developing a group understanding of the problem by hearing from 
experts on the problem. The team would employ “How Might We” notes to contribute to the 
team understanding of gaps in service or questions about how the team might improve the 
process. On Tuesday, the team would map the process and develop the goal. On Wednesday, 
the sprint team would sketch solutions and create storyboards for the process. The team would 
also use “heat-map” type sticker voting to determine which sketches to incorporate into the new 
process. On Thursday, the team would develop a working prototype. On Friday, the team would 
test the prototype on users. To modify the recommended sprint days to fit the time constraints 
and the unique needs of sponsored projects, Fridays session developed into a day devoted to 
designing the process. SPOs would need to test the process over the course of several months after 
the sprint session. 

Day 1: Understanding 

The sprint Facilitator explained the origin of the sprint with software teams and Google Ventures 
and discussed that the session would be an abbreviated version, piloted as alternative problem¬ 
solving model. The team would be reinventing the departments RPPR process throughout the 
course of the week. The team identified a “Scrum Master” who would keep the team on task and 
alert the team by striking a toy xylophone when the team drifted off topic. The SPO Manager 
would serve as the “Decider” and would assist by making the tough decisions, as needed, 
throughout the week. The SPO team invited two Research Business Coordinators and two 
Grants and Contracts Officers to be a part of the sprint team as well. The Research Business 
Coordinators manage the grant budgets and personnel and their perspective would be valuable to 
the process. The Grants and Contracts Officers issue subawards and communicate with subsites 
and the SPO team considered that their input on the RPPR process would be valued as well. 

Chiu proposes that people who do not share an understanding of the immediate problem may 
work together collaboratively to generate multiple perspectives and synthesize them to form an 
effective solution. Sprint team members did not share a universal understanding of the problem. 
By bringing this divergent team together and achieving a shared understanding, the sprint would 
allow the team to bring their different perspectives to develop a solution. Two experts were on 
hand to discuss the problems with the RPPR process and to go over the RPPR form in detail. 
The sprint team included both seasoned Sponsored Project Officers who had submitted dozens 
of RPPRs, new staff who had never submitted a report, and Research Business Coordinators who 
have traditionally contributed a piece of the RPPR for submission and Grants and Contracts 
Officers who may contribute to the process in the future. On the first day, the Director was on 
hand to explain the issues he was seeing come up in the RPPRs. The team created a list of the 
issues he reviewed and asked questions. The team also contributed by compiling lists of “How 
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Might We” notes. These notes gave team members the opportunity to identify opportunities for 
improvement in the process. “How Might We...improve communication with investigators about 
RPPR deadlines?” or “How Might We...ensure all documentation is available from the subsite?” 
The team went through each section of the RPPR in detail to identify the different roles that 
contribute and the time points of interaction in the process. The team ended the Monday session 
by identifying the goal for the week to be: Accurate, compliant, timely reporting by clarifying and 
redefining roles and responsibilities and streamlining the process. 

Critical to the process of team learning is the concept of psychological group safety. In safe 
learning environments, team members feel comfortable asking questions, taking risks, and sharing 
perspectives (Edmondson, 2001). The sprint model attempts to inoculate team members from 
interpersonal anxiety by offering them a distraction-free zone (no electronics) and a dedicated 
space and time to learn from experts and from each other about the process and problems. 
Coordinated action is best accomplished when individuals can synchronize their thoughts, 
feelings, and behavior (Hackman, 1992) and the sprint model offers individuals a safe place 
to learn, share, build, and accomplish in a deadline-driven team environment. Membership 
continuity and familiarity influence group mood and stability (Bartel, 2000); since the sprint 
model promotes intimacy and familiarity among members who are tasked to show up and 
contribute to a shared and specific purpose within the teams’ short duration, the sprint model 
offers strong continuity and builds familiarity quickly. In traditional sprints, team members spend 
the majority of those five days together, breeding trust and comfort among team members. The 
greater the degree of stability, the stronger the teams mood convergence. 

Before concluding Mondays session, the team discussed Tuesdays plans to map the their 
understanding of the process and organize the “How Might We” notes. Monday was an intensive 
day of learning and questioning. Team members seemed overloaded with information, but as they 
were packing up, several expressed hope that the team could improve the RPPR problem with 
use of the sprint. They expressed frustration with the department’s traditional workgroup model, 
citing that it was time-consuming and did not produce results efficiently. 

Day 2: Mapping 

Tuesday’s task was to create a simple map of the process (5-15 steps) that would illustrate the team’s 
understanding of how the process currently worked and help identify flaws or gaps in the process. 
The team quickly determined that they first wanted to draw a quick graph of the different roles 
involved in the RPPRprocess, since the investigator, the SPO, the RBC, the GCO, and the signing 
officer all had different roles to play at unique times and in relationship to the RPPR form. The 
Facilitator helped graph form sections A-H and the team isolated the roles involved with each 
section. This helped the team feel more unified and clear on the sections discussed on Monday. 

The map began with the moment of “RPPR Awareness” and ended with “RPPR Submitted and 
Uploaded.” Defining the middle section of the map was more challenging. The team processed 
backwards in time from the end point and then forward from the beginning until able to define the 
middle zone tasks and handoff points accurately. It was a challenge for the team not to recommend 
solutions to improve the process at this point. The team struggled against this barrier in the sprint 
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format initially, since seeing the map immediately triggered awareness of flaws and dialogue about 
how it could improve. Department workgroups not only allow for this free-form idea generation, 
but encourage it. In workgroup sessions, teams are often free to follow a new idea or solution 
and explore it through brainstorming. However, evidence has shown that brainstorming sessions 
do not produce more average quality ideas; in Diehl and Stoebes study, they determined that 
production blocking , or the brainstorming condition of waiting in turn to present ideas while 
others speak, yields fewer average quality ideas than situations in which individuals produce their 
own ideas or write their ideas on paper while others speak. Group brainstorming doesn’t tend to 
work because dominant, outspoken personalities tend to “win” in those sessions, while quiet or 
new staffers can be overlooked (Novellino, 2016). 

The purpose of the sprint mapping exercise is to coalesce group understanding of the existing 
process, as it related to the RPPR form detailed in Mondays session. 



Figure 1. Mapping the RPPR process. 


Once the team was satisfied with the map, the Facilitator began reviewing the “How Might We” 
notes from Mondays session, allowing the team to determine where they fit into the map or if 
they should be on the “parking lot” for discussion at a later date. The “How Might We” notes 
would help the team determine critical solution needs for Wednesdays sketching session. 
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Figure 2. “How We Might” notes enhance understanding of process flaws. 


The team identified that there was a lot of potential for improvement around the Sponsored 
Project Officers’ final review of the RPPR, some potential new involvement for the Grants and 
Contracts Officers in contacting the subsites or collecting subsite information for the RPPR, 
some ideas for improvement at the moment of RPPR awareness, and a potential change in the 
Research Business Coordinators’ involvement in entering personnel into the RPPR. 

Day 3: Sketching 

The sketching day in the sprint most significantly departs from the department’s problem-solving 
traditions. In workgroup sessions, staff occasionally map processes and learn from experts on 
a topic, but the concept of individually developing solutions inside of a collaborative group 
experience was new. After talking about the problem for two days, the team was keen to begin 
developing solutions. 

The Facilitator explained Knapp’s concept of “Crazy 8’s”: team members fold a blank sheet of 
paper in half four times, then unfold it, to get eight equal rectangles. The team had twenty minutes 
to develop a sketch and was free to get up and look at the map and notes before beginning. With 
limited time to develop a sketch, ideas are faster and staff members experience less self-editing. 
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The team experienced one round of Crazy 8’s, but it may have been more fruitful to do two 
shorter sessions (Dinakaren, 2013) instead. 

The sketching session yielded surprising results. It was incredibly difficult to develop a sketching 
concept, and the sketches the team developed were very text-heavy. This made them challenging 
to read and understand without the artist explaining the sketch. Each team member s sketch boxes 
were almost paragraphs explaining what happened next. The “sketching” element was minimal. 
Perhaps research administration processes lend themselves to more text and fewer diagrams. Or 
perhaps the sketching exercise needed further explanation. Did the team need words to explain 
what happened next or how the proposed changes would impact another persons role or part 
of the RPPR form? Perhaps the value of the sketching session was in helping individual sprint 
memebers organize and explore their own solutions for presentation to the team. More study is 
needed on this in future sprint sessions. 



Figure 3. Sketching example. 


Knapp recommends a few sketching sessions and then developing those sketches into storyboards 
(Sprint, 2016). The sprint team conducted one longer sketching session and eliminated the 
storyboards to save time. This may have been a mistake. The storyboards would have helped 
crystalize the content of the sketches; in future sprint sessions, the storyboard concept should 
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be reintroduced. The team felt rushed on the sketching day and could have used more time to 
develop and analyze the sketches as potential solutions. Despite the sketches’ limitations in the 
department sprint, the team universally saw the sketching day as valuable in the post-sprint survey. 
Developing individual solutions within a team was a valuable part of the success of the sprint and 
the team felt invested in contributing their individual ideas within the safety of the sprint session. 

Additionally, the sketches were surprising in that they were difficult to silently critique and grasp 
without explanation from the author of each sketch. The team allowed the authors to explain 
their sketches and concepts before moving on to vote on the ones that that added the most value 
to improving the RPPRprocess. 

The team placed the sketches on the map and voted on pieces of the sketches that contained 
the most valuable contributions to the process improvement. The Facilitator passed out green 
stickers and each person had four stickers to place on the sketches in silence. The Decider had 
more stickers to use to vote. Silent voting with stickers was a valuable piece of the team effort. 
Team members recommended that future sprints allow pieces of sketches to be cut apart and 
moved around, as this would promote recombining the best ideas from different sketches. The 
storyboard concept may have promoted this recombination aspect as well and should certainly 
be re-introduced into future sprints to more fully explore how that element could contribute to 
the iterative process. 

Day 4: Prototyping 

By Thursday, the team was ready to build a new process and timeline to submission, based on 
shared understanding of the process, the most valuable “How Might We” notes, and the sketched 
ideas determined to contribute most to the process from the voting session. The Facilitator drew 
five timelines on the whiteboard, beginning at the moment of RPPR awareness and ending at 
the SPO uploading the final copy of the report into grant management system. The five lines 
represented each role that was to be involved in the process: the PI, the SPO, the RBC, the GCO, 
and the Authorized Official. The team began the mapping session on Tuesday by defining how 
the different roles interacted with the RPPR form, so it made sense to identify the different 
places where those roles came into play in the new process and how the team might refine those 
intersections in support of increased accuracy and compliance. 

Next, the team identified key time points in the process: the notice of award, 120, 90, 60, and 30 
days before the report was due and placed tasks into the timeline of roles, using ideas from the 
sketches and “How Might We” notes to guide discussion. The sprint team clarified important 
handoff intersections between roles, discussed potential changes in responsibilities related to the All 
Personnel report and to contacting subsites and obtaining required documentations and budgets. 

The new maps helped the team identify the materials needed to empower these changes in 
process and guide the interactions. The team determined that it wanted an overall RPPR Process 
Checklist that would serve as a roadmap for all department roles in each RPPR submission, from 
notice of award through the upload of the final document. That document would be the sprint 
teams primary “product” by the end of the day Friday. However, the team identified the need 
for ancillary materials. The SPOs would create email templates that they would use to contact 
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investigators at different time points in the process. The first would be a template for contacting 
investigators at the time of Notice of Award and the second one would be an email that would 
go out to investigators at the 60-day mark before due date. That 60-day email would include 
language about routing the RPPR to the SPO. The SPOs would also create a final review checklist 
for the RPPR. The Grants and Contracts Officers would create an email template they would 
use to contact subsites to solicit documentation and budgets and a review checklist for verifying 
all subsite documents and budgets are correct at two weeks from submission. The teams goal for 
Friday would be the creation of the RPPR Process Checklist, and due to a shortage of time, the 
team would need to develop the ancillary materials outside of the sprint. 

Day 5: Designing 

Friday was a rush. After five days of collaboration that included individual problem-solving 
opportunities, the team was working together very well. Google conducted a study, entitled Project 
Aristotle , that attempted to quantify what makes good teams successful. The study found that 
conversational turn-taking and empathy help teams develop trust among one another and assure 
team members that they are being heard. The teams that can develop those skills and norms are 
high performing (Duhigg, 2016). By Friday, the sprint team had developed trust, conversational 
turn-taking and good listening skills. It had morphed into a high performing team. The Scrum 
Master role was largely forgotten, as team members were highly focused on achieving the goal and 
contributing to completing the product by the end of the two-hour session. The team had forged 
a strong bond, and by the close of Fridays session, had developed a working draft of the RPPR 
Process Checklist. 

The team took the final ten minutes of Fridays session to discuss impression of the sprint as a 
problem-solving method in the department. The informal feedback session was positive, with 
team members saying that they would choose to be a part of a sprint again to solve a problem, 
specifically when given the choice of a sprint or a workgroup. The team felt that the time 
devoted to the sprint was insufficient, claiming to need three or four hours each day, or a couple 
of strategically placed three-hour days within the sprint week. The sprint team had developed 
a draft document outlining the new process and had identified related collateral materials and 
templates, but the time allotted in the sprint had been insufficient to develop all materials and to 
review their use. That sensation of just having clearly identified what the team needed to develop 
and then ending before the creation of those materials engendered frustration that would have 
been alleviated if we’d had more time allotted for the sprint. The team was able to begin building 
momentum towards an idea or decision and ended for the day. It was challenging to pick up 
immediately the next day at the same energy level and understanding. 

Sprint Follow-up Sessions 

The Decider scheduled two follow-up sessions for the sprint team in the weeks that followed the 
event. In these meetings, the team continued developing the supporting materials for the RPPR 
Process (RPPR Process Checklist, SPO Final Review Checklist, Subcontract Review Checklist, 
and email templates for key interaction moments in the process). The completed RPPR Checklist 
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and Subcontract Review Checklists are fillable PDFs that multiple parties can contribute to 
completing over time. The SPO Final Review is an online form with JotForm. It was much more 
challenging to motivate the team to produce materials outside of the sprint week. 


A. Cover Page * 

1. Verify all data fields are completed and accurate (most fields self-populate from the proposal, but confirm ALL data} 

2. Add Signing Official (Aaron L'fferman) 

3. Add Administrative Official (SPO) 


Yes No N/A 

o o o 
o o o 
o o o 


B. Accomplishments * 

1. Verify all data fields have been completed (PI completes the majorin' of this section} 

2. Confirm: grant number/titles of reneuais/supplements are accurate 

3. Do grad students have effort applied' 

4.1s this a T. K. R25. R13 or D43' 


Yes 

No 

N/A 

O 

o 

o 

O 

o 

0 

o 

o 

0 

o 

o 

0 


C. Products - 


1. Verify all data has been completed (PI completes a majority of this section, but confirm all fields are complete 
2Are any publications listed as non-compiianr' If ves. discuss with PI 

3-Did the PI identify an\ inventions.’patents? If yes. confirm with the Office of Tech Licensing that we reported in iEdison 


Yes \'o N/A 

O O O 

o o o 

o o o 


D. Participants * 

Yes No N/A 


1. Confirm all data fields have beer, completed O O O 

2. Verify. "Enter die All Personnel Report for each person who w orked on the project at least one person month per year during 
the reporting period. If personnel ore key or post-doc an eRA Commons ID is required. For all other personnel, list name, 
degree, project role, and cal month (no DOB or S5N) 

3. Subsites'’ If yes. enter All Personnel data for subsite O O O 

4. Work with RBC PI to address level of effort or new key personnel O O O 

5. Work with PL'Admin to verify- changes in Other Support and ensure this is included for any kev personnel changes in active O O O 

support since the last reporting period 


6. Confirm the completed Other Support does not list active effort ov er 12 cal months (100%). If over, work with PL "RBC to make O O O 
changes pnor to submission 

7. Confirm with the PI if there are any charges in the Multi-PI Leadership Plan O O O 


Figure 4. RPPR Final Checklist for Review. 
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Feedback on the Sprint Session 

Two weeks after the sprint session, all members of the sprint team completed the online anonymous 
survey. When asked what could have improved the sprint session, respondents overwhelming 
chose: Dedicated room space (62.5%) and Afore time dedicated to the sprint (62.5%). Prior education 
on the problem (37.5%), Increased group participation (25%), and Clearer understanding of how 
the sprint would work (25%) also scored highly. The team moved rooms three times throughout 
the week, and it was a challenge to travel the large whiteboard to each room and get set up and 
cleaned up on time each day. A single dedicated space in which to conduct the sprint would 
have been ideal. In this adaptation of the sprint model, the department allocated one-third of the 
advised time for the sprint. While the team may not have needed the full six hours a day, more 
time is needed to yield a truly successful adaption for sponsored projects use of the problem¬ 
solving model. The team felt rushed on several of the days and had to cut out some elements like 
storyboarding that may have really helped define the process and product earlier in the week. 


Table 1. What could have improved the sprint session? 


More time dedicated to the sprint 

62.50% 

Dedicated room space 

62.50% 

Prior education on the problem 

37.50% 

Clearer explanation of how the sprint would work 

25.00% 

Increased group participation during the sprint 

25.00% 

Daily take-away materials/handouts 

12.50% 

Improved facilitation/leadership of the sprint session 

12.50% 

Fewer sprint follow up sessions 

12.50% 

More individuals participating 

0.00% 

Fewer individuals participating 

0.00% 

Less time dedicated to the sprint 

0.00% 

More sprint follow up sessions 

0.00% 

More communication regarding the sprint 

0.00% 


When asked what day of the week specifically needed more time, responses varied. Prototyping 
day (score of 3.88) edged out Sketching (3.14), but the other three days also scored some votes 
with participants as well ( Designing , 2.88; Understanding , 2.75; Mapping , 2.71). The data seems 
to indicate that the team could have used more time on all of the days of the sprint. Teams may see 
increased efficiency and effectiveness in sponsored projects sprints with 3-4 hours a day devoted 
to the process. 
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Table 2. Given the need to solve a complex problem in our department, rate these problem¬ 
solving mechanisms in order of your preference with 1 being your first choice. 



1 

2 

3 

4 

5 

Workgroup 

12.50% 

12.50% 

12.50% 

25.00% 

37.50% 

Email 

11.11% 

0.00% 

22.22% 

22.22% 

44.44% 

Sprint 

44.44% 

44.44% 

11.11% 

0.00% 

0.00% 

Department Training 

0.00% 

11.11% 

33.33% 

33.33% 

22.22% 

Individual problem-solving 
followed by discussing a possible 
solution with manager 

33.33% 

33.33% 

22.22% 

11.11% 

0.00% 


Team members saw the sketching day as the most successful segment of the sprint. This day 
departs most significantly from the department’s commonly used problem-solving methods 
of brainstorming in work groups. On the sketching day, the team quietly sketched and solved 
problems independently, and then discussed and voted on their sketches and recommendations. 
Team members relished the opportunity to solve the problem on their own and then present 
their idea for review. When the survey asked the team to rate their preferred problem-solving 
mechanism for complex problems, they chose the Sprint (4.33) but tellingly, Individualproblem¬ 
solving andpresentingsolutions to a manager was the second choice (3.99), with Workgroup (2.38), 
Department training (2.33) and Email (2.11) following in the distance. 

Table 3. Which of the five days of the sprint was the most successful? 


Day 1: Understanding 

0.00% 

Day 2: Mapping the existing problem 

0.00% 

Day 3: Sketching and “How We Might” Notes 

50.00% 

Day 4: Prototyping/Mapping our new process 

25.00% 

Day 5: Designing our process 

25.00% 


This data, when combined with the interest in the sketchingday, seems to indicate that the sketching 
day may have appealed because it brought this preference for individual problem-solving into the 
collaborative process of the sprint in a way that workgroups, the most common problem-solving 
mechanisms, do not. With their focus on brainstorming and group collaboration, workgroups 
do not allow for individual solutions and they can be challenging for more passive team members 
who struggle to contribute when faced with more vocal peers. Workgroups that build trust and 
conversational turn-taking can be high performing, but those dominated by a stronger voice will 
struggle. Workgroups that incorporate time for individual problem solving may see an increase in 
yields. The sketching day in the sprint model provides staff with the opportunity to individually 
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problem solve and then equitably discuss and vote on the concepts without the influence of 
strong personalities that often impacts the brainstorming sessions in workgroups. In the 1987 
study, Diehl and Stroebe recommended this same concept in their study: 

Because blocking slows down the generation of ideas in groups, it might be more effective to 
ask subjects first to develop their ideas in individual sessions and next have these ideas discussed 
and evaluated in a group session. The task of the group would then consist of evaluation rather 
than production of ideas. This procedure might comb the advantage of group and individual 
sessions without making unnecessary demands on individual time. (pp. 508-509) 

The team found the prototyping day to be the most challenging day of the sprint (83.33%). On 
our prototyping day, the team struggled to merge understanding, mapping, sketching, and notes 
into a product to develop. It took the better part of an hour to formulate and identify the product. 
An hour would not have been a problem within the context of a four-hour sprint day, but with 
only two hours to use, that hour ate away at half of that sessions productivity. 


Table 4. If you could choose to double the time allotted on just one of the days of the sprint, 
which day would you choose? Rank them in order of preference for extra time, with 1 being 
your first choice. 



1 

2 

3 

4 

5 

Day 1: Understanding 

25.00% 

0.00% 

25.00% 

25.00% 

25.00% 

Day 2: Mapping the existing problem 

0.00% 

28.57% 

28.57% 

28.57% 

14.29% 

Day 3: Sketching and “How We Might” Notes 

0.00% 

42.86% 

42.86% 

0.00% 

14.29% 

Day 4: Prototyping/Mapping our new process 

62.50% 

0.00% 

0.00% 

37.50% 

0.00% 

Day 5: Designing our process 

12.50% 

37.50% 

12.50% 

0.00% 

37.50% 


All nine of the respondents indicated that they would recommend the sprint model to solve future 
department problem and eight of the nine responded that they would be willing to participate in 
a future department sprint. All but one of the team members were satisfied with the checklists, 
materials, and process created as a result of the sprint. 

Follow Up to the Sprint 

In the months that followed the sprint, the team struggled to produce the remaining three 
deliverables. During the sprint sessions, the team determined a need for three email templates: 
an email to investigators at the time of the award that advises the investigator on the RPPR 
submission due date, an email to the investigator sixty days before the RPPR report is due, 
and an email to subrecipient to request their documentation and information for the RPPR 
report. Additionally, the sprint team identified the need for a consistent naming convention on 
documents and files, both for the sprint and throughout their processes. It is possible that sprint 
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members do not view these remaining tasks as significant and meaningful contributions and are, 
therefore, less motivated to complete them outside of the sprint sessions. It may be necessary to 
better connect completion of sprint-originated tasks outside of the sprint with the meaningful 
aspects of sponsored research in future sprint sessions. Additionally, sprint team members may see 
these final three auxiliary products as less important than the primary product, and are, therefore, 
less willing to carve out time in their daily tasks to complete them. Ultimately, sprint teams should 
strive to produce the primary product as well as any ancillary materials in the course of the sprint 
session to ensure maximum effectiveness. 

Table 5. Would you recommend our department consider the sprint model to solve future 
problems ? 


Yes 

100.00% 

No 

0.00% 


Conclusion 

The data on the sprint conducted by Sponsored Projects at The Research Institute at Nationwide 
Childrens Hospital indicates that the sprint model would be a successful and welcome way to 
improve future complex department processes. Increasing the allocation of time for the sprint 
to four hours a day, gaining a dedicated and consistent room space for the session, and providing 
advance information on how a sprint works so participants feel prepared to participate fully 
would improve the sprint experience for all members. It may also be useful for the Facilitator 
to send out a summary of the problem and educational materials on the process to help increase 
team readiness in advance of the sprint session. 

While a sprint does bind up those team members’ time and limit the department’s ability to 
provide service during the session, the sprint offers the chance to maximize problem-solving. 
When ten people engage in a one-hour monthly workgroup over a year (120 hours), problem¬ 
solving moves slowly, not everyone can always attend, staff turnover results in stagnation, and 
groups must spend a portion of each one-hour session getting everyone up to speed and re-focused, 
while dedicating 100 hours to an abbreviated sprint session produced a working prototype of a 
complex process without team members experiencing committee burn-out and without having 
to account for staff turnover within the team. The sprint feedback was overwhelmingly positive 
because a sprint combines individual problem-solving preferences with safe group spaces for 
learning and problem-solving and intense and focused collaboration and decision making; these 
factors empower the team to produce fast-paced, holistic solutions to complex problems. 

In looking to fields like software and manufacturing, where process improvement is critical to 
marketplace success, sponsored projects offices can develop new ways to collaborate and solve 
the problems unique to research administration. The adapted sprint model proposed here is 
designed to be an experiment in alternative problem-solving mechanism and is not intended to be 
a universal blueprint of how best to adapt the sprint for all institutions. However, institutions that 


The Journal of Research Administration, (47)2 







110 Raubenolt 


are willing to learn from and adapt methods from other fields create opportunities to filter those 
problems through a new lens and potentially uncover solutions in a way that supports both the 
individual problem solving and rich collaborative connections necessary to promote innovation 
and agility in Sponsored Research and compliance needs. 
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